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Abstract 


The reoptimization of a Point-to-Multipoint (P2MP) Traffic 
Engineering (TE) Label Switched Path (LSP) may be triggered based on 
the need to reoptimize an individual source-to-leaf (S2L) sub-LSP or 
a set of S2L sub-LSPs, both using the Sub-Group-based reoptimization 
method, or the entire P2MP-TE LSP tree using the Make-Before-Break 
(MBB) method. This document discusses the application of the 
existing mechanisms for path reoptimization of loosely routed Point- 
to-Point (P2P) TE LSPs to the P2MP-TE LSPs, identifies issues in 
doing so, and defines procedures to address them. When reoptimizing 
a large number of S2L sub-LSPs in a tree using the Sub-Group-based 
reoptimization method, the S2L sub-LSP descriptor list may need to be 
semantically fragmented. This document defines the notion of a 
fragment identifier to help recipient nodes unambiguously reconstruct 
the fragmented S2L sub-LSP descriptor list. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 7841. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc8149. 
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Les 


Introduction 


This document defines Resource Reservation Protocol - Traffic 
Engineering (RSVP-TE) [RFC2205] [RFC3209] signaling extensions for 
reoptimizing loosely routed Point-to-Multipoint (P2MP) Traffic 
Engineering (TE) Label Switched Paths (LSPs) [RFC4875] ina 
Multiprotocol Label Switching (MPLS) or Generalized MPLS (GMPLS) 
[RFC3473] network. 


A P2MP-TE LSP is comprised of one or more source-to-leaf (S2L) 
sub-LSPs. A loosely routed P2MP-TE S2L sub-LSP is defined as one 
whose path does not contain the full explicit route identifying each 
node along the path to the egress node at the time of its signaling 
by the ingress node. Such an S2L sub-LSP is signaled with no 
Explicit Route Object (ERO) [RFC3209], with an ERO that contains at 
least one "loose next hop", or with an ERO that contains an abstract 
node that identifies more than one node. This is often the case with 
inter-domain P2MP-TE LSPs where a Path Computation Element (PCE) is 
not used [RFC5440]. 


As per [RFC4875], an ingress node may reoptimize the entire P2MP-TE 
LSP tree by re-signaling all its S2L sub-LSPs using the 
Make-Before-Break (MBB) method, or it may reoptimize an individual 
S2L sub-LSP or a set of S2L sub-LSPs, i.e., an individual destination 
or a set of destinations, both using the Sub-Group-based 
reoptimization method. 


[RFC4736] defines an RSVP signaling procedure for reoptimizing the 
path(s) of loosely routed Point-to-Point (P2P) TE LSP(s). The 
mechanisms listed in [RFC4736] include a method for the ingress node 
to trigger a new path re-evaluation request and a method for the 
midpoint node to send a notification regarding the availability of a 
preferred path. This document discusses the application of those 
mechanisms to the reoptimization of loosely routed P2MP-TE LSPs, 
identifies issues in doing so, and defines procedures to address 
them. 


For reoptimizing a group of S2L sub-LSPs in a tree using the 
Sub-Group-based reoptimization method, an S2L sub-LSP descriptor list 
can be used to signal one or more S2L sub-LSPs in an RSVP message. 
This RSVP message may need to be semantically fragmented when a large 
number of S2L sub-LSPs are added to the descriptor list. This 
document defines the notion of a fragment identifier to help 
recipient nodes unambiguously reconstruct the fragmented S2L sub-LSP 
descriptor list. 
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2. Conventions Used in This Document 

2.1. Key Word Definitions 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


2.2. Abbreviations 


ABR: Area Border Router. 


ERO: Explicit Route Object. 
LSP: Label Switched Path. 
LSR: Label Switching Router. 
RRO: Record Route Object. 
S2L sub-LSP: Source-to-leaf sub-LSP. 
TE LSP: Traffic Engineering LSP. 
2.3. Terminology 
This document defines the following terms: 
o Ingress node: Head-end / source node of the TE LSP. 
o Egress node: Tail-end / destination node of the TE LSP. 


It is assumed that the reader is also familiar with the terminology 
in [RFC4736] and [RFC4875]. 
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3. Overview 


[RFC4736] defines RSVP signaling extensions for reoptimizing loosely 
routed P2P TE LSPs as follows: 


o A midpoint LSR that expands loose next hop(s) sends a solicited or 
unsolicited PathErr with Notify error code 25 (as defined in 
[RFC3209]), with sub-code 6 to indicate "Preferable Path Exists" 
to the ingress node. 


o An ingress node triggers a path re-evaluation request at all 
midpoint LSRs that expand loose next hop(s) by setting the "Path 
Re-evaluation Request" flag (0x20) in the SESSION_ATTRIBUTES 
object in the Path message. 


o The ingress node, upon receiving this PathErr with the Notify 
error code (either solicited or unsolicited), initiates the 
reoptimization of the LSP, using the MBB method with a different 
LSP-ID. 


The following sections discuss the issues that may arise when 
applying the mechanisms defined in [RFC4736] for reoptimizing loosely 
routed P2MP-TE LSPs. 


3.1. Loosely Routed Inter-domain P2MP-TE LSP Tree 


An example of a loosely routed inter-domain P2MP-TE LSP tree is shown 
in Figure 1. In this example, the P2MP-TE LSP tree consists of three 
S2L sub-LSPs, to destinations (i.e., leafs) R10, R11, and R12 from 
the ingress node (i.e., source) R1. Nodes R2 and R5 are branch 
nodes, and nodes ABR3, ABR4, ABR7, ABR8, and ABR9 are ABRs. For the 
S2L sub-LSP to destination R10, nodes ABR3, ABR7, and R10 are defined 
as loose next hops. For the S2L sub-LSP to destination R11, nodes 
ABR3, ABR8, and R11 are defined as loose next hops. For the S2L 
sub-LSP to destination R12, nodes ABR4, ABR9, and R12 are defined as 
loose next hops. 
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<-—-areal--><-—-area0--><-area2-> 


ABR7---R10 
/ 
/ 
ABR3---R5 
/ \ 
/ \ 
R1---R2 ABR8---R11 
\ 
\ 
ABR4--—R6 
\ 
\ 
ABR9---R12 


Figure 1: Example of Loosely Routed Inter-domain P2MP-TE LSP Tree 
Existing Mechanism for Tree-Based P2MP-TE LSP Reoptimization 


The mechanisms defined in [RFC4736] can be easily applied to trigger 
the reoptimization of an individual S2L sub-LSP or a group of S2L 
sub-LSPs. However, to apply those mechanisms for triggering the 
reoptimization of a P2MP-TE LSP tree, an ingress node needs to send 
path re-evaluation requests on all (typically hundreds) of the 

S2L sub-LSPs, and the midpoint LSR needs to send PathErrs with the 
Notify error code for all S2L sub-LSPs. Such mechanisms may lead to 
the following issues: 


o A midpoint LSR that expands loose next hop(s) may have to 
accumulate the received path re-evaluation request(s) for all S2L 
sub-LSPs (e.g., by using a wait timer) and interpret them as a 
reoptimization request for the whole P2MP-TE LSP tree. Otherwise, 
a midpoint LSR may prematurely send a "Preferable Path Exists" 
notification for one S2L sub-LSP or a subset of S2L sub-LSPs. 


o Similarly, the ingress node may have to heuristically determine 
when to perform P2MP-TE LSP tree reoptimization and when to 
perform S2L sub-LSP reoptimization. For example, an 
implementation may choose to delay reoptimization long enough to 
allow all PathErrs to be received. Such timer-based procedures 
may produce undesired results. 


o The ingress node that receives (un)solicited PathErr(s) with the 
Notify error code for one or more individual S2L sub-LSPs may 
prematurely start reoptimizing the subset of S2L sub-LSPs. 
However, as mentioned in [RFC4875], Section 14.2, sucha 
Sub-Group-based reoptimization procedure may result in data 
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duplication that can be avoided if the entire P2MP-TE LSP tree is 
reoptimized using the MBB method with a different LSP-ID, 
especially if the ingress node eventually receives PathErrs with 
the Notify error code for all S2L sub-LSPs of the P2MP-TE 

LSP tree. 


In order to address the above-mentioned issues and to align the 
reoptimization of P2MP-TE LSPs with P2P LSPs [RFC4736], a mechanism 
is needed to trigger the reoptimization of the LSP tree by 
re-signaling all S2L sub-LSPs with a different LSP-ID. To meet this 
requirement, this document defines RSVP-TE signaling extensions for 
the ingress node to trigger the re-evaluation of the P2MP LSP tree on 
every hop that has a next hop defined as a loose or abstract hop for 
one or more S2L sub-LSP paths, and a midpoint LSR to signal to the 
ingress node that a preferable LSP tree exists (compared to the 
current path) or that the whole P2MP-TE LSP must be reoptimized 
(because of maintenance required on the TE LSP path) (see 

Section 4.1). 


3.3. Existing Mechanism for Sub-Group-Based P2MP-TE LSP Reoptimization 


Applying the procedures discussed in [RFC4736] in conjunction with 
the Sub-Group-based reoptimization procedures ([RFC4875], 

Section 14.2), an ingress node MAY trigger path re-evaluation 
requests for a set of S2L sub-LSPs in a single Path message using an 
S2L sub-LSP descriptor list. Similarly, a midpoint LSR may send a 
PathErr with Notify error code 25 and sub-code 6 ("Preferable Path 
Exists") containing a list of S2L sub-LSPs transiting through the LSR 
using an S2L sub-LSP descriptor list to notify the ingress node. 
This method can be used for reoptimizing a sub-group of S2L sub-LSPs 
within an LSP tree using the same LSP-ID. This method can alleviate 
the scaling issue associated with sending RSVP messages for 
individual S2L sub-LSPs. However, this procedure can lead to the 
following issues when used to reoptimize the LSP tree: 


o A Path message that is intended to carry the path re-evaluation 
request as defined in [RFC4736] with a full list of S2L sub-LSPs 
in an S2L sub-LSP descriptor list will be decomposed at branching 
LSRs, and only a subset of the S2L sub-LSPs that are routed over 
the same next hop will be added in the descriptor list of the Path 
message propagated to downstream midpoint LSRs. Consequently, 
when a preferable path exists at such midpoint LSRs, the PathErr 
with the Notify error code can only include the subset of S2L 
sub-LSPs traversing the LSR. In this case, at the ingress node 
there is no way to distinguish which mode of reoptimization to 
invoke, i.e., Sub-Group-based reoptimization using the same LSP-ID 
or tree-based reoptimization using a different LSP-ID. 
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o An LSR may semantically fragment a large RSVP message (when a 
combined message may not be large enough to fit all S2L sub-LSPs). 
In this case, the ingress node may receive multiple PathErrs with 
subsets of S2L sub-LSPs in each (due to either the combined Path 
message getting fragmented or the combined PathErr message getting 
fragmented) and would require additional logic to determine how to 
reoptimize the LSP tree (for example, waiting for some time to 
aggregate all possible PathErr messages before taking an action). 
When fragmented, RSVP messages may arrive out of order, and the 
receiver has no way of knowing the beginning and end of the S2L 
sub-LSP list. 


In order to address the above-mentioned issues caused by semantic 
fragmentation of an RSVP message, this document defines a new 
fragment identifier object for the S2L sub-LSP descriptor list when 
combining a large number of S2L sub-LSPs in an RSVP message (see 
Section 4.2). 


Signaling Extensions for Loosely Routed P2MP-TE LSP Reoptimization 
1. Tree-Based Reoptimization 
To evaluate a P2MP-TE LSP tree on midpoint LSRs that expand loose 


next hop(s), an ingress node MAY send a Path message with the 
"P2MP-TE Tree Re-evaluation Request" flag set (bit number 14 in the 


Attribute Flags TLV) as defined in this document. The ingress node 
selects one of the S2L sub-LSPs of the P2MP-TE LSP tree transiting a 
midpoint LSR to trigger the re-evaluation request. The ingress node 


MAY send a re-evaluation request to each border LSR on the path of 
the LSP tree. 


A midpoint LSR that expands loose next hop(s) for one or more S2L 
sub-LSP paths does the following upon receiving a Path message with 
the "P2MP-TE Tree Re-evaluation Request" flag set: 


o The midpoint LSR MUST check for a preferable P2MP-TE LSP tree by 
re-evaluating all S2L sub-LSPs that are expanded paths of the 
loose next hops of the P2MP-TE LSP. 


o If a preferable P2MP-TE LSP tree is found, the midpoint LSR MUST 
send to the ingress node an RSVP PathErr with Notify error code 25 
[RFC3209] and sub-code 13 ("Preferable P2MP-TE Tree Exists)" as 
defined in this document. The midpoint LSR, in turn, SHOULD NOT 
propagate the "P2MP-TE Tree Re-evaluation Request" flag in the 
subsequent RSVP Path messages sent downstream for the re-evaluated 
P2MP-TE LSP. 
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o If no preferable tree for P2MP-TE LSPs can be found, the midpoint 
LSR that expands loose next hop(s) for one or more S2L sub-LSP 
paths MUST propagate the request downstream by setting the 
"P2MP-TE Tree Re-evaluation Request" flag in the LSP_ATTRIBUTES 
object of the RSVP Path message. 


A midpoint LSR MAY send an unsolicited PathErr with the Notify error 
code and the "Preferable P2MP-TE Tree Exists" sub-code to the ingress 
node to notify the ingress node of a preferred P2MP-TE LSP tree when 
it determines that it exists. In this case, the midpoint LSR that 
expands loose next hop(s) for one or more S2L sub-LSP paths selects 
one of the S2L sub-LSPs of the P2MP-TE LSP tree to send this PathErr 
message to the ingress node. The midpoint LSR SHOULD consider how 
frequently it chooses to send such a PathErr, considering that both 
(1) a PathErr may be lost during its transit to the ingress node and 
(2) the ingress node may choose not to reoptimize the LSP when such a 
PathErr is received. 


The sending of an RSVP PathErr with the Notify error code and the 
"Preferable P2MP-TE Tree Exists" sub-code to the ingress node 
notifies the ingress node of the existence of a preferable P2MP-TE 
LSP tree, and upon receiving this PathErr, the ingress node SHOULD 
trigger the reoptimization of the LSP, using the MBB method with a 
different LSP-ID. 


Sub-Group-Based Reoptimization Using Fragment Identifier 


It might be preferable, as per [RFC4875], to reoptimize the entire 
P2MP-TE LSP by re-signaling all of its S2L sub-LSPs (Section 14.1 
("Make-before-Break") in [RFC4875]) or to reoptimize an individual 
S2L sub-LSP or a group of S2L sub-LSPs, i.e., an individual 
destination or a group of destinations (Section 14.2 
("Sub-Group-Based Re-Optimization") in [RFC4875]), both using the 
same LSP-ID. For loosely routed S2L sub-LSPs, this can be achieved 
by using the procedures defined in [RFC4736] to reoptimize one or 
more S2L sub-LSPs of the P2MP-TE LSP. 


An ingress node may trigger path re-evaluation requests using the 
procedures defined in [RFC4736] for a set of S2L sub-LSPs by 
combining multiple Path messages using an S2L sub-LSP descriptor list 
[RFC4875]. An S2L sub-LSP descriptor list is created using a series 
of S2L_SUB_LSP objects as defined in [RFC4875]. Similarly, a 
midpoint LSR may send a PathErr with Notify error code 25 and 
sub-code 6 ("Preferable Path Exists") containing a list of S2L 
sub-LSPs transiting through the LSR using an S2L sub-LSP descriptor 
list to notify the ingress node of preferable paths available. 
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The S2L_SUB_LSP_FRAG object defined in this document is optional, 
with the following exceptions: 


o As per [RFC4875], Section 5.2.3 ("Transit Fragmentation of Path 
State Information"), when a Path message is not large enough to 
fit all S2L sub-LSPs in the descriptor list, an LSR may 
semantically fragment the message. In this case, the LSR MUST add 
the S2L_SUB_LSP_FRAG object defined in this document for each 
fragment in the S2L sub-LSP descriptor to be able to rebuild the 
list from the received fragments that may arrive out of order. 


o In any other situation where an RSVP message needs to be 
fragmented, an LSR MUST add the S2L_SUB_LSP_FRAG object for each 
fragment in the S2L sub-LSP descriptor. 


A midpoint LSR SHOULD wait to accumulate all S2L sub-LSPs before 
attempting to re-evaluate a preferable path when a Path message for 
"Path Re-evaluation Request" is received with the S2L_SUB_LSP_FRAG 
object. If a midpoint LSR does not receive all fragments of the Path 
message (for example, when fragments are lost) within a configurable 
time interval, it SHOULD trigger the re-evaluation of all S2L 
sub-LSPs of the P2MP-TE LSP transiting on the node. A midpoint LSR 
MUST receive at least one fragment of the Path message to trigger 
this behavior. 


An ingress node SHOULD wait to accumulate all S2L sub-LSPs before 
attempting to trigger reoptimization when a PathErr with the Notify 
error code and the "Preferable Path Exists" sub-code is received with 
an S2L_SUB_LSP_FRAG object. If an ingress node does not receive all 
fragments of the PathErr message (for example, when fragments are 
lost) within a configurable time interval, it SHOULD trigger the 
reoptimization of all S2L sub-LSPs of the P2MP-TE LSP transiting on 
the midpoint node that had sent the PathErr message. An ingress node 
MUST receive at least one fragment of the PathErr message to trigger 
this behavior. 


The S2L_SUB_LSP_FRAG object defined in this document has a wider 
applicability in addition to the P2MP-TE LSP reoptimization. It can 
also be used (in Path and Resv messages) to set up a new P2MP-TE LSP 
and to send other PathErr messages as well as Path Tear and Resv Tear 
messages for a set of S2L sub-LSPs. This is outside the scope of 
this document. 
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5. Message and Object Definitions 
5.1. "P2MP-TE Tree Re-evaluation Request" Flag 


In order to trigger a tree re-evaluation request, a new flag in the 
Attribute Flags TLV of the LSP_ATTRIBUTES object [RFC5420] is defined 
by this document: 


Bit Number 14: "P2MP-TE Tree Re-evaluation Request" flag 


The "P2MP-TE Tree Re-evaluation Request" flag is meaningful in a Path 
message of a P2MP-TE S2L sub-LSP and is inserted by the ingress node 
using the message format defined in [RFC6510]. 


Zas "Preferable P2MP-TE Tree Exists" Path Error Sub-code 


In order to indicate to an ingress node that a preferable P2MP-TE LSP 
tree exists, the following new sub-code for PathErr messages with 
Notify error code 25 [RFC3209] is defined by this document: 


Sub-code 13: "Preferable P2MP-TE Tree Exists" sub-code 


When a preferable path for a P2MP-TE LSP tree exists, the midpoint 
LSR sends a solicited or unsolicited "Preferable P2MP-TE Tree Exists" 
sub-code with a PathErr message with Notify error code 25 to the 
ingress node of the P2MP-TE LSP. 


5.3. Fragment Identifier for S2L Sub-LSP Descriptor 


The S2L_SUB_LSP object [RFC4875] identifies a particular S2L sub-LSP 
belonging to the P2MP-TE LSP. An S2L sub-LSP descriptor list is 
created using a series of S2L_SUB_LSP objects as defined in 
[RFC4875]. The RSVP message may need to be semantically fragmented 
[RFC4875] due to a large number of S2L sub-LSPs added in the 
descriptor list, and such fragments may be received out of order. To 
be able to rebuild the fragmented S2L sub-LSP descriptor list 
correctly, the following object is defined to identify the fragments: 


S2L_SUB_LSP_FRAG: Class Number 204 
0 1 2 3 


OLEA IO SAO 6 8 GS ON AS Aor FB. OO: A 
E 


| Length (8 bytes) | Class Num 204 | C-Type 1 
Hota AA ASA AA E AA AA 
| Fragment ID | Fragments Tot.| Fragment Num. | 


E 
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Fragment ID: 16-bit integer in the range of 1 to 65535. 


This value is incremented for each new RSVP message that needs to 
be semantically fragmented. The fragment ID is reset to 1 when it 
reaches the maximum value of 65535. The scope of the fragment ID 
is limited to the RSVP message type (e.g., Path) carrying the 
fragment. In other words, fragment IDs do not have any 
correlation between different RSVP message types (e.g., Path and 
PathErr). The receiver does not check to ensure that the 
consecutive new RSVP messages (e.g., Path messages) are received 
with fragment IDs incremented by 1. 


Fragments Total: 8-bit integer in the range of 1 to 255. 


This value indicates the number of fragments sent for the given 
RSVP message. This value MUST be the same in all fragmented RSVP 
messages with a common fragment ID. 


Fragment Number: 8-bit integer in the range of 1 to 255. 


This value indicates the position of this fragment in the given 
RSVP message. 


The format of an S2L sub-LSP descriptor message is as follows: 


<S2L sub-LSP descriptor> ::= 
[ <S2L_SUB_LSP_FRAG> | 
<S2L_SUB_LSP> 
[ <P2MP SECONDARY_EXPLICIT_ROUTE> ] 


The S2L SUB LSP FRAG object is added before adding the S2L SUB LSP 
object in the semantically fragmented RSVP message. 


6. Compatibility 


The LSP_ATTRIBUTES object has been defined in [RFC5420] and its 
message formats in [RFC6510] with class numbers in the form 11bbbbbb, 
which ensures compatibility with non-supporting nodes. Per 
[RFC2205], nodes not supporting this extension will ignore the new 
flag defined for this object in this document and will forward it 
without modification. 


The S2L SUB LSP FRAG object has been defined with class numbers in 
the form 11bbbbbb, which ensures compatibility with non-supporting 
nodes. Per [RFC2205], nodes not supporting this object will ignore 
the object and will forward it without modification. 
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7. IANA Considerations 
IANA has performed the actions described below. 
7.1. "P2MP-TE Tree Re-evaluation Request" Flag 


IANA maintains the "Resource Reservation Protocol-Traffic Engineering 
(RSVP-TE) Parameters" registry (see 
<http://www.iana.org/assignments/rsvp-te-parameters>). Per 

Section 5.1 of this document, IANA has registered a new flag in the 
"Attribute Flags" registry. This new flag is defined for the 
Attribute Flags TLV in the LSP_ATTRIBUTES object [RFC5420]. 


+----- Ter Ho Ho +----- +----- Ho + 
| Bit | Name | Attribute| Attribute| RRO | ERO | Reference | 
No Flags Flags 
Path Resv 
+----- $ Ho Ho +----- +----- Ka E + 
| | P2MP-TE Tree | Yes | No | No | No | This | 
| 14 | Re-evaluation | | | | | document | 
| | Request | | | | | | 
+----- AA E Ho Ho +==-==- +----- Ho + 
7.2. “Preferable P2MP-TE Tree Exists" Path Error Sub-code 


IANA maintains the "Resource Reservation Protocol (RSVP) Parameters" 
registry (see <http://www.iana.org/assignments/rsvp-parameters>). 
Per Section 5.2 of this document, IANA has registered a new error 
code in the "Sub-Codes - 25 Notify Error" sub-registry of the "Error 
Codes and Globally-Defined Error Value Sub-Codes" registry. 
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As defined in [RFC3209], error code 25 in the ERROR_SPEC object 
corresponds to a PathErr with the Notify error. This document adds a 


new "Preferable P2MP-TE Tree Exists" sub-code for this PathErr as 
follows: 

+---------- +-------------------- +--------- +--------- +----------- + 
| Value | Description | PathErr | PathErr | Reference | 
| | | Code | Name | | 
+---------- +-------------------- 4+--------- 4+--------- Ho + 
| 13 | Preferable P2MP-TE | 25 | Notify | This | 
| | Tree Exists | | Error | document | 
+---------- +-------------------- +--------- +--------- +----------- + 

Fragment Identifier for S2L Sub-LSP Descriptor 
IANA maintains the "Resource Reservation Protocol (RSVP) Parameters" 


registry (see <http://www.iana.org/assignments/rsvp-parameters>). 
Per Section 5.3 of this document, IANA has registered a new class 
number in the "Class Names, Class Numbers, and Class Types" registry. 


AK === AZ O $2 + 
| Class Number | Class Name | Reference 
AZ A ar an aana wana aa AA $2 + 
| 204 | S2L_SUB_LSP_FRAG | This document | 
AZ AZ = $2 + 
IANA has also created the "Class Types or C-Types - 204 

S2L SUB LSP FRAG" registry and populated it as follows: 
t--------—--—--—--—-—- tons Daa maan aa aa AA AAA AZ + 
| Value | Description | Reference 

AK aa 5-5 ------- AZ SAA na E A AZ + 
per | S2L_SUB_LSP_FRAG | This document | 
$ AZ O $ 5-5-5 === + 


Security Considerations 


This document defines RSVP-TE 
ingress node of a P2MP-TE LSP 
tree downstream of a node and 
ingress node of the existence 
PathErr message. As per [RFC4 


sub-LSP spanning multiple domains, 


signaling extensions to allow an 

to request the re-evaluation of the LSP 
to allow a midpoint LSR to notify the 
of a preferable tree by sending a 

736], in the case of a P2MP-TE LSP S2L 
it may be desirable for a midpoint 


LSR to modify the RSVP PathErr message to preserve confidentiality 


across domains. 
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This document also defines a fragment identifier for the S2L sub-LSP 
descriptor when combining a large number of S2L sub-LSPs in an RSVP 
message and the message needs to be semantically fragmented. The 
introduction of the fragment identifier, by itself, introduces no 
additional information to signaling. For a general discussion on 
security issues related to MPLS and GMPLS, see the MPLS/GMPLS 
security framework [RFC5920]. 
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